Skip to main content
Version 2.0.4

Moonchain Supernode V2

In our zkEVM SupernodeV2, there are two important parts to a Moonchain Supernode, which are connected over the engine API:

  • mxc-geth
  • mxc-client

MXC geth​

The mxc-geth repository is a customized version of taiko-geth tailored to integrate MXprotocol specifications. Functioning as an IoT Web3 platform, it interfaces with an LPWAN cluster as described here previously. Similar to Ethereum's L1/L2 execution engines, mxc-geth monitors and processes new IoT transactions within the network. These transactions are ececuted on the EVM, maintaining the latest state and comprehensive database of current IoT data. Subsequently, it submits proofs using Zero-Knowledge cryptography for enhanced security and privacy.

MXC client​

The compiled binary bin/mxc-client serves as the primary interface, offering three essential sub-commands:

  1. driver: Ensures synchronization between the IoT execution engine's chain and the MXCL1 contract. This command directs the IoT execution engine to maintain alignment with the designated MXCL1 contract.
  2. proposer: Facilitates the proposal of new transactions from the IoT execution engine's transaction pool to the MXCL1 contrct. This sub-command is responsible for initiating new transaction proposals within the ecosystem.
  3. prover: Manages the verification process by requesting Zero-Knowledge (ZK) proofs from the zkEVM. Additionally, it submits transactions to validate proposed blocks, confirming their integrity and validity within the blockchain network.

Driver​

The Driver component within the MXC client software functions as an IoT consensus client. It actively monitors the MXC layer 1 protocol contract for incoming IoT blocks. Upon detecting new blocks, the Driver directs the connected IoT execution engine to incorporate these blocks into its local chain using the Engine API.

Engine API​

The Engine API serves as the interface through which the Driver communicates with the IoT execution engine. It enables the Driver to instruct the execution engine to perform tasks such as inserting new blocks into its local chain or handling chain reorganizations when necessary. This API facilitates seamless coordination between the MXC client's Driver and the underlying IoT execution engine, ensuring synchronization and consistency across the network.

Chain synchronization process​

NOTE

In MXC, a block's timestamp can be equal to its parent block's timestamp, which differs from the original Ethereum protocol. Therefore, it is permissible for there to be two MXCL1.proposeBlock transactions included in one L1 block. This flexibility in timestamp handling supports Moonchain's specific blockchain architecture and operational requirements.

The driver component in MXC plays a crucial role in coordinating with the IoT execution engine. It begins by informing the IoT execution engine about the latest verified IoT head from the MXC contract and attempts initial synchronization through peer-to-peer (P2P) communication. The driver monitors the sync progress of the execution engine, transitioning to inserting verified blocks into its local chain via the Engine API if no new sync progress is detected over time.

Once the IoT execution engine is synchronized with the latest verified IoT head, the driver subscribes to MXCL1.BlockProposed events. Upon receiving notification of a new pending block proposal, the following chronological order can be perceived.

  1. Retrieve the MXCL1.proposeBlock L1 transaction associated with the event.
  2. Decode the transaction's calldata to extract the txList (transaction list) and block metadata.
  3. Validate the txList against the predefined rules specified in MXC to ensure its compliance and integrity within the blockchain network.

If the txList is valid:

  1. Construct a deterministic MXCL2.anchor transaction based on the protocol's rules, placing it as the first transaction in the proposed txList.
  2. Utilize the validated txList and decoded block metadata to compose a deterministic IoT block.
  3. Instruct the IoT execution engine to insert this assembled block and designate it as the current canonical chain's head using the Engine API.

If the txList is invalid:

  1. Generate a MXCL2.invalidateBlock transaction and assemble an IoT block containing only this transaction.
  2. Direct the IoT execution engine to insert this block without setting it as the chain's head via the Engine API.